本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

周委員站在管理室前，手上拿著一份報價，問林總幹事：「這個一定要整套換嗎？原本的就不能修？」

我走近才知道，他們在討論包裹登記設備。林總幹事把故障情況和兩種處理方式說了一遍，師父則補充夜班實際用起來的問題：登記卡住時得先留紀錄，恢復後再補，住戶來領件也容易多等一會兒。

周委員沒有直接答應。他請總幹事把維修和更換的費用、保固與後續支援一起列出來，方便帶回去討論。總幹事收好資料，說會再向廠商確認。

等他們談完，我問師父：「每天用的是你們，最清楚好不好用的也是你們，怎麼不能直接決定？」

一項採購，會有不同的人參與

師父說，自己能說明現場情況，但社區支出有它的決策安排。知道設備不好用，和決定花多少錢換什麼設備，是不同的責任。他不能只因為自己操作最久，就替大家答應一筆支出。

我說：「那做企業產品也是這樣？最常找你抱怨的人，可能沒有辦法買？」

師父點頭。他用一個 AI 客服草稿工具說明。

客服人員每天使用，最清楚哪種回答需要反覆改；
客服主管在意整體處理速度、品質和人力；
資訊人員需要確認系統如何接入、資料流向哪裡；
採購和預算負責人則要處理費用與交易條件。

這些角色在小公司可能由一兩個人兼任，但在大公司則可能分得很細。重點是把實際參與的人找出來，知道他們各自要確認什麼。

我問師父：「聽起來你要把每個人都說服一遍。」

師父說，至少要知道誰會使用、誰負責成果、誰可以投入預算，以及誰能提出必須先處理的條件。

否則一直和使用者討論畫面，最後才發現公司不允許資料放進這個 AI 服務，前面的進度就得重新評估。

使用者的支持，怎麼變成公司願意採用的理由？

我問師父：「假設客服真的很喜歡，也願意幫你向主管介紹，那不是很好嗎？」

師父說很好，這種願意協助內部溝通的人，能幫忙解釋實際情境，也比較知道應該找誰一起談。但不能把整份銷售工作丟給他，讓他拿著一張產品截圖去面對主管所有問題。

例如主管想知道導入之後是否能減少處理時間，就需要先定義比較方式；資訊人員問有哪些資料會離開公司，就要有清楚的資料說明。這些應該由產品團隊協助準備，讓內部支持者有材料可以溝通。

我追問：「那簡報是不是要做很多個版本？對不同的人說不同的故事？」

師父回答，同一件事可以從不同責任說明，但內容得一致。不能向客服說回覆仍由人確認，向主管又保證人力可以立刻減半；也不能對資訊部門承諾資料不留存，卻沒有確認系統實際怎麼做。

他建議用一個共同流程串起來：資料如何進入、誰會操作、怎麼檢查結果，以及出了問題誰處理。不同的人可以在自己的責任位置提出問題，團隊再把未解的條件記下。

這時林總幹事回來拿剛才漏掉的附件，問師父夜班遇到卡住時，能不能把發生時間一併留下。師父說可以，已有的紀錄也能提供。總幹事道謝，說有具體情況，才比較好請廠商判斷。

付錢的人不每天使用，也需要知道結果

我等總幹事離開，問師父：「可是預算負責人不用產品，他怎麼判斷值不值得？」

師父說，就要讓採用理由能被檢查。假設公司想縮短回覆時間，要說清楚目前怎麼算、試用涵蓋哪些類型、品質有沒有下降。若這個工具只是讓少數特殊案例比較方便，也可以承認，讓對方評估是否值得投入。

我說：「那是不是只聽付錢的人就好？畢竟他能決定買不買。」

師父回答，買了卻沒人願意用，後面仍然會出問題。使用者遇到的麻煩不能忽略，預算和導入條件也要一起處理。兩边的問題需要放在同一個採用計畫裡，而不是誰有權力就永遠只聽誰。

他拿剛才的設備討論作為有限的對照。保全需要能正常登記、住戶希望少等一下、委員需要知道費用和維護安排。這些要求可以一起存在。社區與企業的治理方式不同，但都不能省略「誰需要確認什麼」這個問題。

今晚談到的規則很實際：企業採購要找出使用、成果、預算與核定各由誰負責，讓每一段都有能確認的資料。 抱怨最多的人能提供重要線索，但一張訂單通常還需要其他人的參與。

周委員走回來時，我以為他又要談設備。他卻問師父，今天是不是有自己的掛號。師父查過紀錄，拿出信件請他簽收。而我也就上樓吃晚餐去了。